1. Field of the Invention
The present invention relates generally to methods and apparatuses for providing a transaction processing system for handling encapsulated transaction messages. More specifically, the invention relates to data structures for encapsulated messages and to systems and methods for processing raw messages into transaction messages that are established to be valid.
2. Description of the Related Art
The conduct of business transactions over computer networks has become an increasingly important part of the U.S. economy over the last several years. In many cases, private networks have been developed to carry transaction messages and message protocols such as Electronic Data Interchange ("EDI") have been developed to specify the form and content of messages.
Internationally, trade documents represent the essential business relationships for import and export. Trade documents include letters of credit, standby letters of credit, bills of lading, certificates of insurance, bankers acceptances, invoices, sight drafts, time drafts, trust receipts, and others. The parties whose relationships these documents represent include the buyer, the seller, banks, shippers, warehouses, and insurers. Trade documents, at base, are paper documents; international trade requires that these papers travel across borders and oceans to consummate a transaction. The use of paper to represent the business relationships between the various parties has always had certain problems and some of these problems yet persist in modem business practice.
Most international trade documents are still on paper and still travel physically. International express package delivery has greatly increased the speed and reliability of this paper movement, but the papers still require large amounts of handling once they arrive, with all the attendant problems of paperwork. The problems with paper are well known. Paper requires human handling, which is more expensive than computer automation. Trade documents are still sometimes generated in multiple, numbered originals to guard against loss. Paper is unsuitable for the speed of modern commerce.
EDI is the state of the art insofar as the elimination of paper in these transaction environments. EDI specifically refers to the standards for data exchange as embodied in the U.S. and by ANSI ASC .times.12 and worldwide by UN EDIFACT. These two standards differ only in detail. EDI, though, has a number of problems itself which have prevented its widespread adoption.
One of the major problems with using, EDI for trade documents is that the process of setting up EDI linkages is burdensome and laborious. The process of "bringing up another trading partner" involves negotiation over exact terms of the interaction. EDI messages only carry the data about particular transactions, and they do not include information about the exact terms of the agreement between the parties sending and receiving messages. EDI standards do not encapsulate information about how the message should be interpreted, how the message is expected to be handled, or the legal relationship between the parties. The lack of message interpretation information associated with the message makes it necessary for two parties that wish to deal with each other unambiguously to engage in the long process if integrating their systems together, and to make sure that the systems remain compatible as they evolve.
Compliance with EDI message format standards does not guarantee that two systems, both compliant to the same standard, will be able to understand each other's messages. The permitted variation in message formats is large enough to allow mutually incomprehensible messages. These messages may appear on the surface to be mutually comprehensible because they are both written according, to the same standard. EDI, however, has no way of distinguishing one variation of a general type of message from another. What is needed is a way of allowing variation and preserving interoperability.
Complex problems arise when different parties attempt to join their private transaction systems. In certain cases, in may be desirable to link systems across a private intranet or internet. Increasingly, it is desired to link systems across the global Internet. Complex specifications are required in order for parties to make their systems compatible. For example, a payment system may require a certain type of message to be coded in a given format, or in alternative formats. Such a payment system may also specify the type of responses that are expected, allowed or required for certain messages. A second system would need to identify the format that is used to the first system when a message is sent to the first system and would also need to specify the expected, allowed and required responses and how those responses would be determined.
Errors or misunderstandings can a rise when a format is misnamed by one system or a sequence of responses is referred to by an incorrect name or by an ambiguous name between such systems. To complicate matters further, names of formats may also change and different versions could be created.
In view of the foregoing, it would be useful if formats and expected sequences could be named in a manner that could prevent systems from having such misunderstandings. When messages are referred to, it would further be useful if two separate systems could unambiguously know that a message or data file being referred to by one system exactly matches a message stored at the other system. Such a system of reference would be especially useful for confirming or acknowledging messages. It would further be useful if duplicate messages sent as a result of the transmission media or method could be positively identified as duplicates and extra messages discarded. It would also be useful if identifiers that identify files that describe how to interpret the message body could be associated with the message body and encapsulated with the message ID and if other message information items such as the recipient and sender authentication information could also be associated with the message body.